Skip to content

Conversation

@chpolste
Copy link
Member

@chpolste chpolste commented Dec 12, 2025

Description

Adds new submodule earthkit.meteo.regimes with classes to define a weather regime classification based on patterns and functions to project anomaly fields onto these patterns to compute a regime index, following the approach of Michel and Rivière (2011).

The implementation aims to cater to users at three levels:

  • High-level: Users that want to apply a regime classification, i.e., compute a regime index, using a preconfigured instance of RegimePatterns from elsewhere. These users only need functions project and standardise.
  • Medium-level: Users that create a new regime classification by instantiating one of the provided subclasses of RegimePatterns (i.e., the required pattern generation is already implemented).
  • Low-level: Users that create a new regime classification and need to implement a new pattern generation scheme in a class inheriting from RegimePatterns.

Classes to represent fixed patterns (ConstantRegimePatterns) and base patterns modulated by a custom scalar function (ModulatedRegimePatterns) are provided with this first implementation. An example notebook shows how to use the data of Grams to recreate their 7-pattern regimes classification and apply it to test data.

Implementations are at array-level with dictionaries used to label outputs based on their association with individual regimes.

Features to consider in follow-up work

  • Higher-level interface compatible with FieldList and xarray
  • Support for grids other than lat-lon
  • Automatic regridding and cropping of input data based on the gridspec in the pattern class with earthkit.regrid
  • Automatic generation of area weights based on the gridspec
  • Tools to extract regime patterns from data (EOFs and clustering methods are most commonly used)

Contributor Declaration

By opening this pull request, I affirm the following:

  • All authors agree to the Contributor License Agreement.
  • The code follows the project's coding standards.
  • I have performed self-review and added comments where needed.
  • I have added or updated tests to verify that my changes are effective and functional.
  • I have run all existing tests and confirmed they pass.

@codecov-commenter
Copy link

codecov-commenter commented Dec 12, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.62%. Comparing base (02051e5) to head (be83b55).

Additional details and impacted files
@@             Coverage Diff             @@
##           develop      #88      +/-   ##
===========================================
+ Coverage    99.58%   99.62%   +0.03%     
===========================================
  Files           14       16       +2     
  Lines          962     1064     +102     
  Branches        15       15              
===========================================
+ Hits           958     1060     +102     
  Misses           2        2              
  Partials         2        2              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@chpolste chpolste marked this pull request as ready for review December 30, 2025 11:23
@sandorkertesz
Copy link
Collaborator

sandorkertesz commented Jan 16, 2026

@chpolste, thank you very much for this development. Since it is related to geography I wonder if earthkit-meteo is the right place for it or it should be in earthkit-geo instead? What do you think?

@chpolste
Copy link
Member Author

The regimes describe geographical patterns within meteorological fields, so it's a bit of both. For me, the meteorological application of regimes as recurrent weather patterns is the primary concern. And I prefer when the vocabulary used in the package matches that of the domain (which to me is meteorology, not geography). If it were to go into earthkit-geo I think the references to "regimes" in the code would have to go in favour of just (geographical) "patterns".

I can see that the spatial aggregation in the computation of the projections/regime index is different to the "grid point-based" approach that most/all existing earthkit-meteo functions take over the spatial domain, so this would in some sense be a "first" for this package.

@chpolste chpolste requested a review from oiffrig January 20, 2026 14:47
Copy link
Collaborator

@oiffrig oiffrig left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me!


Parameters
----------
field : array_like
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's worth documenting the expected array dimensions (and the relationship between the arguments and return dimensions)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants